在 Kubernetes 上跑数据库，真的没有意义么？

点击卡片，关注 InsideMySQL

今天在 zhufeng 的微信群聊了一个蛮有意思的话题：数据库放在 K8S 有啥好处？

没想到，这个话题很快打开了码农们的讨论。其中 zhufeng 态度异常鲜明地表达了自己的观点：

我就喜欢 zhufeng 的直接，鲜明的表达自己的观点，非常棒。

反观德哥，总是躲躲闪闪，不敢正面回答问题。

当然，光口嗨是不行的，zhufeng 作为一代 MySQL 专家，也给出了自己的推导：

随后，zhufeng又补充到，这个话题他在《一个数据库十年老兵的思考与总结》有过更为清晰的说明，具体如下：

       现在流行新技术docker/k8s，有人经常问到我，你们MySQL用docker了吗?我通常是用两个成语回复，分别是隔靴搔痒，作茧自缚，你想上k8s，是为了解决什么问题?编排部署安装装找资源的问题?MySQL是一个有状态的大型通用数据库，这么重存储的服务，找资源安装，问题很大吗?又说是资源隔离的问题，资源隔离的需求很紧迫吗?单机单实例就不说了，即使在单机多实例的情况下，也没几个实例，并且MySQL本身内部就是多线程的，均衡问题也比较好，同一台机器上一个实例影响其它实例的案例少之又少，所以这需求有那么紧迫吗? 而且对于使用MySQL 没有上到一定量级的情况下，非k8s的自动化平台就可以很好的解决资源部署安装编排的问题，为了解决这个问题，创造一个上k8s的大问题，这样就有点和初衷背道而驰了。同时 k8s 是一个新的技术栈，支撑它上线，是需要另一个专业团队来做的，投入产出比非常低。

        我反过来再问一下，MySQL本身的问题你解决完了吗?慢查询有没有好的工具去优化?主从切换能不能不影响业务?机器挂了能不能不丢数据?数据库服务能不能做到不同机房的多活?自动化 SQL审核可以自助服务了吗?如果哪个没做到，那就先放弃k8s吧。再者，我们专业的MySQL运维技术人员，非要作茧自线博，给MySQL套一个壳，出了问题，是壳的问题?还是 MySQL本身的问题?当引入一个变量的时候，可服务率肯定就会有一定程度的下降，因为99.99%*99.99%的结果是99.98%。

万万没想到，zhufeng 对 K8S 上跑数据库有这么大的意见。在我和 zhufeng 短暂沟（交）通（锋）后，zhufeng 的最终表达的观点为：

综合上述zhufeng的所有说法，其实他想要表达的是：数据库上K8S收益并不大，应该做其他优先级更高的事情，所以小公司没有必要搞。

zhufeng 说得没有错，非常有理。然而，这样的观点表示他已经是 old school 的数据库专家。

很多时候，技术人员太喜欢专注于技术细节，而忘了数据库作为一款产品最核心的问题是什么。

在线业务用户需要数据库支持 Hash Join 么？大概率是不需要的。

离线业务用户需要数据库支持事务功能么？大概率是不需要的。

业务需要数据库支持数据分片，自动扩缩容么？大概率是不需要的。

那 zhufeng 说的不是对的么？有优先级更高的事情做。比如SQL审核、慢查询等。

是的，zhufeng 观点正确之处在于数据库需要先满足业务的需求，这是最高优先级。即：数据库需要满足业务需求。

然而，作为 DBA 应该很清楚，业务需求不是一锤子买卖，今天满足了，明天就没有了。做的一些工具、平台，只是为了提升码农们的工作效率。

这些事情也就是 DBA 的 daily work。所以，即便是数据库上云了，或者云数据库了，依然需要 DBA 完成很多日常的工作。

几年前 DBA 们还在人人自危云数据库会导致数据库“自动驾驶”，无事可干。

但现在还有 DBA 担心么？不会了。

所以，K8S 上跑数据库的意义何在？

首先，我们要看到的是作为产品， K8S 解决的是什么问题。下面是百度百科对于 K8S 的定义：

Kubernetes，简称K8s，是用8代替名字中间的8个字符“ubernete”而成的缩写。是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful），Kubernetes提供了应用部署，规划，更新，维护的一种机制。

再看看 K8S 自己的定位：

Kubernetes, also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications.

可以看到，Kubernetes 的目标是让部署容器化的应用简单并且高效。

在之前的数据库时代，数据库就是一个二进制安装包，配置、启动等需要由人工或半自动脚本的方式进行。

到了 PaaS 的云数据库时代，云平台完成不少自动化的工作，效率提升，部署也简单了。他仅仅是一个运行的数据库，解决了高可用、资源动态扩缩容、并且提供了一些对 DBA 友好的可视化操作平台。

但是 PaaS 云数据库基于 KVM 虚拟机技术，存在额外的性能开销。但这个问题并不大，只是技术细节。最为核心的点在于云数据库没有解决业务多环境部署的问题。

多环境是指如果一个业务部署在多个云环境呢？比如腾讯云、阿里云，在这两个云环境下，数据库体验和使用或许并不是完全一致的。

有同学说，没有多少业务会有这样的需求。

的确，这样的概率也不大。

但是业务的研发过程需要开发环境、自测环境、联调环境、UAT环境、生产环境等，这么多环境如何保证和最终的生产环境是一致的呢？又如何保证各个环境数据库的表结构、索引又都是一致的呢？

比如线上生产环境的 MySQL 是一主两从，ACK为1的半同步复制，并对业务提供两个 MySQL Router 作为读写代理。

换句话说，将数据库跑在 K8S 上时，我们的目标并不是简单地提供一个可运行的数据库实例，而是一个数据库服务，也就是我们常说的 DBaaS 。

这款数据库服务不仅提供数据库访问，还提供数据库实例的自愈、故障转移、负载均衡、备份、监控、日常操作等一系列的数据库配套工具。

同时，这个数据库服务可以通过镜像、编排、容器等技术快速复制到不同研发和生产环境，对业务用户提供极致的 CI、CD、CO 体验。

随着 K8S 的不断演进，整个研发流程已经发生了很大的改变，未来的IT架构也将是云原生的。

因此，不是数据库需要跑在 K8S 上，而是业务需要数据库提供这样的服务能力。

还有不少同学认为有状态的数据库不适合跑在 K8S 上，有部分原因也是因为受到《数据库不适合Docker及容器化的7大原因》这篇文章的影响。

问题是，那篇文章已经是5年前的老文，那时的 K8S 还很不成熟。

现在的 K8S 提供了 Stateful Set、Local Persist Volume，Operator等针对数据库这类有状态服务的一系列功能，使得数据库已经可以很好地运行在 K8S 上。

MySQL 官方最近也发表了MySQL Operator for Kubernetes，可以将 InnoDB Cluster 部署在 K8S 上，同时提供了 MySQL Router、备份等功能，算是给 MySQL 数据库跑在 K8S 上打了个样：

感兴趣的同学可以看：https://dev.mysql.com/doc/mysql-operator/en/

PostgreSQL、TiDB 也有各自的 Operator，可以将数据库快速地部署在 K8S 上，以此成为一款 Cloud Native 数据库。

All in all，虽然将数据库部署在 K8S 上还存在这样或者那样的问题，但 Cloud Native Database，DBaaS的趋势不可逆转。

时代的巨轮滚滚向前，让我们一起见证 Cloud Native Database 时代的来临吧！

以上。

今日思考题

问题1： 哪种字符集既能存GBK字符，又能存储UTF-8字符？业务代码该如何写呢？

想要知道思考题答案的小伙伴，欢迎加入 IMG 官方社区高端群 。

欢迎加入 IMG 官方社区高端VIP群 。

入群请加姜老师个人微信 82946772，并备注：码农入VIP群

IMG 官方社区高端群是订阅制的，不过也就99元/年，权当请姜老师喝杯咖啡。

在会员期间你可以享受到下面的福利：

• 突破微信群人数500的限制，以后所有高端群小伙伴可以在一起吹水；

• 提供 IMG 公众号每篇技术文章最后遗留问题的标准答案；

• 技术圈的江湖八卦，比如某数据库出局某行的原委，某大V被新领导GZ；

• IMG社区技术嘉年华大会门票5折优惠；

• 姜老师夫妇的私密分享，包括技术、工作、投资、相亲、移民等热门话题；

• 会员每邀请新会员入群，可以享受59元的返利（把年费赚回来😄）；3

往期推荐